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X.509 Certificate General-Purpose Extended Key 
Usage (EKU) for Document Signing 


Abstract 


RFC 5280 specifies several extended key purpose identifiers (KeyPurposelds) for X.509 
certificates. This document defines a general-purpose Document-Signing KeyPurposeld for 
inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. Document- 
Signing applications may reguire that the EKU extension be present and that a Document-Signing 
KeyPurposeld be indicated in order for the certificate to be acceptable to that Document-Signing 
application. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9336. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
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with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


[RFC5280] specifies several extended key purpose identifiers (KeyPurposelds) for X.509 
certificates. In addition, the IANA repository "SMI Security for PKIX Extended Key Purpose" 
[RFC7299] includes a number of KeyPurposelds. While usage of the anyExtendedKeyUsage 
KeyPurposeld is bad practice for publicly trusted certificates, there is no public and general 
KeyPurposeld explicitly assigned for Document Signing. The current practice is to use id-kp- 
emailProtection, id-kp-codeSigning, or a vendor-defined KeyPurposeld for general Document- 
Signing purposes. 


In circumstances where code signing and S/MIME certificates are also used for Document 
Signing, technical or policy changes made to the code signing and S/MIME ecosystem may cause 
unexpected behaviors or have an adverse impact such as decreased cryptographic agility on the 
Document-Signing ecosystem and vice versa. 
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Vendor-defined KeyPurposelds that are used in a PKI governed by the vendor or a group of 
vendors pose no interoperability concern. Appropriating, or misappropriating as the case may 
be, KeyPurposelDs for use outside of their originally intended vendor or group of vendors 
controlled environment can introduce problems, the impact of which is difficult to determine. 


Therefore, it is not favorable to use a vendor-defined KeyPurposeld for signing a document that 
is not governed by the vendor. 


This document defines an extended key purpose identifier for Document Signing. 


2. Conventions and Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Extended Key Purpose for Document Signing 


This specification defines the KeyPurposeld id-kp-documentSigning. 


As described in [RFC5280], "[i]£ the [Extended Key Usage] extension is present, then the certificate 
MUST only be used for one ofthe purposes indicated." [RFC5280] also notes that "[i]f multiple 
[key] purposes are indicated the application need not recognize all purposes indicated, as long as 
the intended purpose is present." 


Document-Signing applications MAY require that the EKU extension be present and that the id- 
kp-documentSigning be indicated in order for the certificate to be acceptable to that Document- 
Signing application. 


The term "Document Signing" in this document refers to digitally signing contents that are 
consumed by people. To be more precise, contents are intended to be shown to a person ina 
printable or displayable form by means of services or software, rather than processed by 
machines. 


3.1. Including the Extended Key Purpose for Document Signing in 
Certificates 


[RFC5280] specifies the EKU X.509 certificate extension for use on the Internet. The extension 
indicates one or more purposes for which the certified public key is valid. The EKU extension can 
be used in conjunction with the key usage extension, which indicates the set of basic 
cryptographic operations for which the certified key may be used. 


The EKU extension syntax is repeated here for convenience: 
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ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeld 


KeyPurposeld ::= OBJECT IDENTIFIER 


As described in [RFC5280], the EKU extension may, at the option of the certificate issuer, be either 
critical or non-critical. 


This specification defines the KeyPurposeld id-kp-documentSigning. Inclusion of this 
KeyPurposeld in a certificate indicates that the public key encoded in the certificate has been 
certified to be used for cryptographic operations on contents that are consumed by people. 


id-kp OBJECT IDENTIFIER ::= 
{ iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) 3 } 


id-kp-documentSigning OBJECT IDENTIFIER ::= { id-kp 36 } 


4. Using the Extended Key Purpose for Document Signing ina 
Certificate 


Our intended use case is people consuming the contents of signed documents. To be more 
precise, contents are intended to be shown to a person in a printable or displayable form by 
means of services or software, rather than processed by machines. The digital signature on the 
contents is to indicate to the recipient of the contents that the content has not changed since it 
was signed by the identity indicated as the subject of the certificate. To validate the digital 
signature that is signed on contents intended to be consumed by people, implementations MAY 
perform the steps below during certificate validation. 


The following procedure is used to examine the KeyPurposeld(s) included in the EKU extension. 
Restrictions on EKU is derived and implemented from (or configured with) the policy to which 
the implementation conforms. 


e If there are no restrictions set for the relying party and the relying party software, the 
certificate is acceptable. 


e If there are restrictions set for the relying party and relying party software, then process the 
KeyPurposeld(s) as described below. 


This procedure is intended to permit or prohibit the presence of a certain KeyPurposeld or 
the complete absence of KeyPurposelds. It is outside the scope of this document, but the 
relying party can permit or prohibit combinations of KeyPurposelds, instead of a single 
KeyPurposeld. A consideration on prohibiting combinations of KeyPurposelds is described in 
the Security Considerations section of this document. If both Excluded KeyPurposeld and 
Permitted KeyPurposeld exist, the relying party or the relying party software processes each 
restriction on Excluded KeyPurposeld first and then processes each restriction on Permitted 
KeyPurposeld. 
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Excluded KeyPurposeld procedure: 
Excluded KeyPurposeld is a KeyPurposeld that the relying party or the relying party 
software prohibits. Examples of Excluded KeyPurposeld include the presence of the 
anyExtendedKeyUsage KeyPurposeld or the complete absence of the EKU extension in a 
certificate. If a KeyPurposeld ofthe certificate meets the conditions set by the Excluded 
KeyPurposeld restriction, the relying party or the relying party software rejects the 
certificate. 


Permitted KeyPurposeld procedure: 
Permitted KeyPurposeld is a KeyPurposeld that the relying party or the relying party 
software accepts. Examples of Permitted KeyPurposeld include the presence ofthis 
general-purpose Document-Signing KeyPurposeld and/or the protocol-specific 
KeyPurposelds that are relevant to Document Signing. If a KeyPurposeld of the certificate 
meets the condition set by a Permitted KeyPurposeld restriction, the certificate is 
acceptable. Otherwise, the relying party or the relying party software rejects the 
certificate. 


When a single application has the capability to process various data formats, the software may 
choose to make the excluded and permitted decisions separately in accordance with the format it 
is handling (e.g., TEXT and PDF). 


5. Implications for a Certification Authority 


The procedures and practices employed by a certification authority MUST ensure that the correct 
values for the EKU extension are inserted in each certificate that is issued. Unless certificates are 
governed by a vendor-specific PKI, certificates that indicate usage for Document Signing MAY 
include the id-kp-documentSigning KeyPurposeld. The inclusion of the id-kp-documentSigning 
KeyPurposeld does not preclude the inclusion of other KeyPurposelds. 


6. Security Considerations 


The usage of the id-kp-documentSigning KeyPurposeld is to provide an alternative to id-kp- 
emailProtection being used for non-email purposes and id-kp-codeSigning being used to sign 
objects other than binary code. This extended key purpose does not introduce new security risks 
but instead reduces existing security risks by providing means to separate other extended key 
purposes used for communication protocols, which include TLS (id-kp-clientAuth) and S/MIME 
(id-kp-emailProtection), in order to minimize the risk of cross-protocol attacks. 


To reduce the risk of specific cross-protocol attacks, the relying party or the relying party 
software may additionally prohibit use of specific combinations of KeyPurposelds. 


While a specific protocol or signing scheme may choose to come up with their own 
KeyPurposelds, some may not have significant motive or resources to set up and manage their 
own KeyPurposelds. This general-purpose Document-Signing KeyPurposeld may be used as a 
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stop-gap for those that intend to define their own Document-Signing KeyPurposeld or those who 
do not intend to set up a KeyPurposeld but still would like to distinguish Document Signing from 
other usages. 


Introduction of this id-kp-documentSigning KeyPurposeld does not introduce any new security 
or privacy concerns. 


7. IANA Considerations 


IANA has registered the following OID in the "SMI Security for PKIX Extended Key Purpose" 
registry (1.3.6.1.5.5.7.3). This OID is defined in Section 3.1. 


Decimal Description References 
36 id-kp-documentSigning RFC 9336 
Table 1 


IANA has also registered the following ASN.1 [X.680] module OID in the "SMI Security for PKIX 
Module Identifier" registry (1.3.6.1.5.5.7.0). This OID is defined in Appendix A. 


Decimal Description References 
104 id-mod-docsign-eku RFC 9336 
Table 2 
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Appendix A. ASN.1 Module 


The following ASN.1 [X.680] module provides the complete definition of the Document-Signing 
KeyPurposeld. 


DocSignEKU { iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) id-mod(@) 
id-mod-docsign-eku(184) } 

DEFINITIONS EXPLICIT TAGS ::= 

BEGIN 

-- EXPORTS ALL -- 

-- IMPORTS NOTHING -- 

== OLD AC 

id-kp OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) kp(3) } 

-- Document-Signing Extended Key Usage -- 

id-kp-documentSigning OBJECT IDENTIFIER ::= { id-kp 36 } 

END 
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